An IC typically employs a reference clock in order to control the timing of events and ensure that movement of data signals are correlated to each other in the IC. Such synchronously clocked ICs contain many memory elements or registers, sometimes as many as tens of millions, all of which need to receive the reference clock signal simultaneously. Since the reference clock signal normally does not have sufficient strength to simultaneously drive all of the registers without signal degradation, clock buffer trees are normally incorporated into the IC to effectively amplify the drive strength of the reference clock signal. Clock buffer trees receive the reference clock and generate much stronger output signals for appropriately driving the registers. The clock buffer trees normally comprise multiple stages, with the number of buffers in each successive stage increasing geometrically over the number of buffers in the immediately preceding stage. The outputs of the buffers of the last stage become the clocks that drive the registers. Each buffer in the last stage typically drives only 5 to 10 registers.
Each buffer stage in the clock buffer tree delays the reference clock signal by some amount of time due to its intrinsic propagation delay. The clock buffer tree is carefully designed to ensure that the propagation delay of all buffers in the same stage are matched. If a proper design is achieved, the buffer tree clock, which corresponds to the outputs of the buffers of the last stage, will synchronously drive all of the registers with multiple output clocks that are replicas of the reference clock input, but shifted in time by a delay that is the sum of propagation delays from the first to the last stage of buffering. This delay is commonly known as clock insertion delay.
With a properly designed and balanced clock buffer tree, the clock insertion delay should be independent of the path of buffer stages that the clock signal traverses before reaching the registers. However, this overall delay produced by the buffer tree can vary due to IC manufacturing process, supply voltage, and temperature variations, known as PVT variations, as well as output load variations. In other words, the buffer tree clock fluctuates with time during normal operation of the IC. This is not a problem if the IC does not require a known, unvarying phase relationship between the buffer tree clock and the reference clock. However, synchronous ICs require a known, unvarying relationship between the buffer tree clock and the reference clock. For these ICs, delay-locked loops (DLLs) are typically used to remove on-chip clock insertion delay in order to maintain a substantially unvarying relationship between the buffer tree clock and the reference clock. A DLL is a negative feedback control system that tracks the delay in the clock buffer tree so as to maintain phase alignment between the phase of the buffer tree clock and that of the reference clock.
A known DLL is shown in FIG. 1. The DLL 1 receives as one of its inputs the system reference clock, CLKREF. The other input of the DLL 1 corresponds to the output 2 of the clock buffer tree 3 that drives the registers 4, which will be referred to as the buffer tree clock, CLKTREE. The buffer tree clock CLKTREE is the feedback used by the DLL 1 to maintain phase alignment of the buffer tree clock CLKTREE to the reference clock CLKREF. Therefore, the buffer tree clock CLKTREE will sometimes be referred to herein as the feedback clock. The DLL 1 has a phase comparator 5 that receives CLKREF and CLKTREE and compares the magnitude and polarity of their phases. The output of the phase comparator 5 is a phase difference signal. A first order loop filter 6 extracts the direct current (dc) component from the output of the phase comparator 5 so that the signal driving the variable delay element 7 is stable and does not pulse. A pulsed input to the variable delay element 7 would generate a corresponding pulsed variable delay and introduce undesirable jitter or timing variations in the output clock. The output of the filter 6 causes the variable delay element 7 to delay CLKREF by an amount that ensures that the phase of CLKTREE will remain aligned with the phase of CLKREF. This is achieved with a DLL 1 output clock CLKDLL that is effectively shifted back in time by the clock insertion delay in the clock buffer tree 3. Thus, with the edges of CLKTREE and CLKREF kept aligned in time by the DLL 1, the registers are effectively clocked by CLKREF.
As stated above, PVT variations can cause the delay produced by the clock buffer tree 3 to vary. Consequently, the delay produced by the clock buffer tree 3 can increase or decrease. If the delay produced by the clock buffer tree 3 increases by a certain amount of time, then the phase comparator 5 will steer the variable delay element 7 to produce a delay that is decreased by that same amount to maintain phase alignment at the clock buffer tree output. Conversely, if the delay produced by the clock buffer tree 3 decreases, then the delay produced by the variable delay element 7 will correspondingly increase. In both cases, the variable delay element 7 shifts CLKREF to maintain phase alignment between CLKREF and CLKTREE.
Because the delays produced by the clock buffer tree 3 can vary over a range of delays due to PVT and register load conditions, the DLL 1 should be capable of delaying the reference clock over a range of delays. Currently, there is no way to test a DLL to determine whether it works over the range of delays needed to maintain alignment between CLKREF and CLKTREE. To date, DLLs are tested by turning the IC on and verifying DLL functionality under some fixed PVT and load conditions corresponding to a constant clock tree buffer delay. Of course, the DLL may work under the conditions and clock buffer tree delay existing at that time and yet not work over a range of conditions and clock buffer tree delays. Consequently, an IC that is determined to work properly when tested in this manner may not work properly in the environment in which it is later employed by the end user. Accordingly, a need exists for a DLL that can be tested over a range of delays and a method for testing the DLL exhaustively over a range of delays.